jit: read a deref-last projection as a value, and put fast2locals on the virtualizable protocol - #1358

…e three #1358 follow-ups (#1374)

* jit: name a virtualizable config whose array lengths were never patched in

`to_optimizer_config` builds `VirtualizableConfig` with `array_lengths:
vec![]` and relies on its caller to fill them in:
`MetaInterp::current_virtualizable_optimizer_config` assigns
`ctx.virtualizable_array_lengths()` one line later, beside the identical patch
of `vable_input_offset`.  That sibling field documents the convention on
itself; `array_lengths` did not.  A length is not a property of the shape —
upstream reads `len(lst)` off the live object in every `virtualizable.py`
accessor and stores it nowhere.

`VirtualizableTracker::init` zips `array_field_offsets` with `array_lengths`,
so a config that declares an array field and carries no length runs that loop
zero times, leaves `state.arrays` empty, and turns every later
`tracked_array_element` into a miss that reads as "this trace had no array
elements".  The `debug_assert!` names that state instead of absorbing it.

Both escapes in the assertion are load-bearing: the state-field macro JIT sets
`track_array_elements = false` and carries its elements through the live
`virtualizable_boxes` shadow, and a virtualizable with no array field has
nothing to seed.

`array_tracking_config_without_lengths_is_named_not_absorbed` has to build the
state by hand, which is itself the statement that no production path produces
it: both writers of `TraceCtx::virtualizable_boxes` set the lengths in the
same statement, `state.rs seed_virtualizable_boxes` passes `vec![array_len]`
on the portal and bridge paths, and
`optimizer_vable_config_matches_registered_virtualizable_when_boxes_active`
already pins the patched result.

Assisted-by: Claude

* interpreter: record why _unpackiterable_known_length_jitlook carries no unroll_safe

The doc comment quotes upstream's `@jit.unroll_safe` along with the body it
ports, which reads as an unfinished port.  It is not one.  Upstream reaches
that body two ways and hints only one of them: `unpackiterable` goes through
`_unpackiterable_known_length`, which is `@jit.dont_look_inside` ("the JIT
stopped looking inside already"), while `unpackiterable_unroll` calls it
directly with an UNPACK_SEQUENCE oparg as `expected_length`.

pyre has neither `unpackiterable_unroll` nor the shim, so `unpackiterable` is
this body's only caller — the one upstream fences off.  Being loopy and
unhinted the graph is rejected by `look_inside_graph` and stays a residual
call, which is the boundary the shim buys upstream.  Carrying the attribute
alone would open that path, with `expected_length` — a red argument on one
graph ~40 callers share — as the unroll bound.

Restoring the split needs more than the attribute:
`#[majit_macros::dont_look_inside]` registers a helper call descriptor, and
`helper_call_kind_for_type` answers `Unsupported` for this signature's
`Result<Vec<PyObjectRef>, PyError>`, so the shim needs an
`extern "C" fn(..) -> i64` publication first.

`test_unroll_safe_inventory` asserts the harvested `unroll_safe` set is a
subset of a reviewed list, plus a named negative for this body.  Subset rather
than equality because a developer's `build/llbc` is routinely older than the
source and can only under-report, which must not red; `builtins::
leading_non_null_count` is the positive control, and its absence skips the
test loudly rather than passing on an artefact too old to say anything.

Assisted-by: Claude

* jit: carry the iterator element type into the next fold

`iter_next_item_type` answered `Int` for a container produced by
`front::range_iter`'s `range()` builtin and `Ref` for every other one.  The
`iter` op carries the iterator, not the container's item type, and a slice of
non-GC items is spelled exactly like a slice of references —
`is_concrete_iter_constructor` collapses `Vec<T>`, `[T; N]` and `Box<[T]>`
onto the same `core::slice::…::iter`.  So the container alone could not
separate them.

`charon-corpus`'s `branch_loop_sum(slice: &[i64], ..)` folds `for &v in
slice`, and its `i64` element was typed as a GC reference.

`result_ty` is not a hint the rtyper overrules: `resolve_call_result_kind`
consults `concretetype` only when `result_ty` is `Unknown`, and
`authoritative_result_types` stamps the derived kind back over it, so the
answer here outranks the rtyper for every graph that gets a JitCode.

The recording site already reads a callee's `Result` payload for
`result_exc_call_results`; `next_call_results` now carries the `Option<T>`
payload the same way, with the `&` a slice iterator adds peeled off by
`strip_ty_wrappers`.  `Ref(Some(root))` normalises back to `Ref(None)` so
every GC-element graph that folds today stamps a byte-identical `result_ty`,
and the range arm answers before the recorded type is consulted, because
`rrange.py ll_rangenext_*` returns `Signed` whatever the Rust range spells.
An unreadable `Option` shape falls back to `Ref(None)`, the answer the fold
assumed unconditionally before.

`branch_loop_sum_next_yields_an_int_element` fails on the previous behaviour
with `left: [Ref(None)], right: [Int]`.

Assisted-by: Claude

* jit: port arraylen_vable to the codewriter

`rewrite_op_getarraysize` (`jtransform.py:808-817`) is the third consumer
of `vable_array_vars`, alongside `rewrite_op_getarrayitem` and
`rewrite_op_setarrayitem`.  The codewriter had the other two and answered
a `len()` over a virtualizable array with a plain `arraylen_gc` on the
raw array pointer.

Adds `OpKind::VableArrayLen`, the `rewrite_op_getarraysize` arm, and the
assembler encoding for the `arraylen_vable/rdd>i` key that
`insns.rs`, `blackhole.rs`, `opimpl_arraylen_vable` and
`bhimpl_arraylen_vable` already carried.  The macro lowering
(`majit-macros` `lower_vable_array_len`) emitted the instruction; the
codewriter path did not.

Assisted-by: Claude

* jit: drop the getfield a virtualizable array field read produced

`rewrite_op_getfield`'s `except VirtualizableArrayField:` handler ends in
`return []` (`jtransform.py:848-857`): registering the base in
`vable_array_vars` is the whole rewrite.  The port kept the op, so a
`getfield_gc_r` of the array pointer stayed in the jitcode and fell
through to the immutability-rank rewrite below.

All three consumers now answer against the vable base, so the read has
no user left.

Assisted-by: Claude

* jit: fix indentation and the descr-pair citation on the arraylen_vable arms

Two of the new match arms landed at the wrong column; `cargo fmt` leaves
them alone because it bails on the enclosing `match` in both files.

The descr-pair comments named `expect_matching_vable_array_descrs`, which
is `pyre-jit`'s assembler.  The runtime that decodes the emitted
`arraylen_vable/rdd>i` is `MIFrame::vable_array_index_pair_at`.

Assisted-by: Claude

* jit: address the #1374 review — gate the vable arms, and peel one reference

`rewrite_op_getfield` runs whether or not `lower_virtualizable` is set,
because the quasi-immutable tail below it does not depend on virtualizable
lowering. Its two virtualizable arms do. With `vable_arrays` set and the flag
off, the array arm registered a base no consumer would read and dropped a read
those consumers still referenced, leaving regalloc an undefined variable.

`strip_ty_wrappers` peels `Ref` repeatedly, so an iterator over `&[&i64]`
recorded its `Option<&&i64>` payload as `Int` and put a pointer in the integer
register bank. `iterator_payload_element` peels the one reference the iterator
adds and leaves the element's own.

Also: require `array_lengths.len() == array_field_offsets.len()` rather than
non-emptiness, since the zip truncates a short vector silently; pin the
`arraylen_vable/rdd>i` wire shape and its descr pair; and fail the unroll_safe
inventory when two harvested paths share a leaf, which is the assumption it
matches on.

Assisted-by: Claude

* jit: read the iterator ADT before peeling, and catch vable array escapes by any route

`iterator_payload_element` peeled one reference off every `next()` payload.  A
slice iterator adds that reference, but the by-value iterators
`is_concrete_iter_constructor` admits do not: `alloc::vec::into_iter::IntoIter`
and `core::array::iter::IntoIter` yield `Option<T>`, so the payload is the
element already.  `Vec<&i64>` and `[&i64; N]` therefore recorded their `&i64`
element as `Int` and put a pointer in the integer register bank -- the mirror
image of the `&[&i64]` defect the peel was added for.  The `next()` receiver
names the iterator ADT; peel only for `core::slice::iter::Iter` / `IterMut`.

`slice_of_refs_sum` and `array_of_refs_sum` carry both shapes in the corpus.
Peeling unconditionally fails the first, never peeling fails
`branch_loop_sum_next_yields_an_int_element`; no fixed answer passes both.

`check_no_vable_array` enumerated four operand positions.  Registering a
variable in `vable_array_vars` drops the `getfield` that defined it, and
nothing prunes dead operations between `transform` and regalloc, so any
operand a kept operation still names is a variable used and never defined.
A fifth route scans every operand of every operation the block kept; it
reports last and least precisely, and it exists because the four are an
enumeration.

`_handle_list_call` carries no `vable_array_vars` check and is owed none:
upstream splits on `resizable`, putting the check on the `do_fixed_list_*`
arms whose receiver is a `GcArray`, and every spelling pyre ports is of the
resizable family with a `W_ListObject` receiver.

Also: decode the assembled bytes in the `arraylen_vable` wire-shape test
rather than only the descr pool order; exercise `lower_virtualizable = false`
on the scalar-field arm as well as the array arm; and run the unroll_safe
leaf-collision check after the CONTROL guard, so a stale artefact is skipped
rather than judged.

Assisted-by: Claude

* majit: cover the untested virtualizable abort paths

`VableArrayIndexNotConcrete` and `GuardSnapshotVableUntyped` had no tests.
Neither fires on the synth corpus (0 across the 374 fixtures that trace,
where `VableEscapedDuringResidualCall` takes 123).

- `array_vable_handlers_with_unpinned_index_surface_index_not_concrete`
  drives `getarrayitem_vable_i` / `setarrayitem_vable_i` with a seeded vable
  ref and an index register holding no concrete value.
- `an_untyped_virtualizable_box_is_not_snapshot_buildable` pins
  `TraceCtx::vable_snapshot_buildable` over an absent box list, an all-typed
  list, and an untyped entry in each of the two positions
  `build_vable_snapshot_boxes` reads separately.
- `build_vable_snapshot_boxes_panics_on_an_untyped_{identity,entry}` pin the
  two `.expect()` calls that predicate keeps unreachable.

Assisted-by: Claude

* majit: drop the optimizer's virtualizable array-element seeding

Both loop-close arms carry the tracer's live `virtualizable_boxes` shadow
into the JUMP as `[reds..., virtualizable_boxes[..-1]]`: the macro
state-field JIT through `JitState::collect_jump_args_with_boxes`, PyFrame
through `jitcode_dispatch::append_virtualizable_boxes`. PyFrame reaches
the second only — nothing under `pyre/` produces `TraceAction::CloseLoop`,
so its `collect_jump_args_with_boxes` override is not called in
production; note that where the override is defined.

`elements_carried_via_shadow` classified PyFrame as not shadow-carried and
kept `track_array_elements` on for it, so `VirtualizableTracker::init`
seeded element state from the trace-entry input args. Remove that seeding,
along with `VirtualizableConfig::track_array_elements`,
`::array_lengths` and the length patch in
`current_virtualizable_optimizer_config`. The standard-path read answers
from the shadow and records no op (`vable_getarrayitem_*_checked`,
pyjitpl.py:1170-1184), and the tracer updates the shadow through
`set_virtualizable_entry_at` without recording one, so a seeded element
box had nothing to fold against and could go stale.

Measured before removal: check.py dynasm 434/434, zero jit-stats counters
moved.

Replace the three tests that pinned the removed length assertion with one
that pins what `ensure_setup` still owes — the identity
`PtrInfo::Virtualizable` install — and state in the tracker's doc which
parts remain and what retiring them would require.

Also check `set_virtualizable_entry_at`'s documented precondition against
`virtualizable_slot_type` instead of only stating it: a non-Ref value in
a Ref slot decodes to NULL through `value_as_ref_bits`.

Assisted-by: Claude